Web sites, such as Internet sites, often provide information, products, services, and the like to their users. Unfortunately, these web sites may be subject to one or more types of security attacks. When a user on a client computer communicates with a web server computer, there is often a need to share information (e.g., authentication information) between the client and the server. For instance, many web sites require users to “register” before their web servers will grant access, to the users. Transactional communications such as these between a client computer and a server computer are at risk of interception or circumvention by a third party.
Presently available authentication services, for example, allow a user to maintain a user account and password for accessing information. The user uses his or her user account and password to access a company intranet, a web server or service, or a private database. As users increasingly rely on authentication services to provide user validation functions, trust has become essential to the success of many of these services. There is also an important trust between the user and an application to which the user is willing to provide credentials. Trustworthiness is affected in part by the steps taken to improve the security of a web service such as an authentication service. A key component in the security of the service is the security of individual user accounts. Penetrating even a single user account can cause a loss of trustworthiness and confidence in the service along with disclosure of confidential user information.
One type of attack is referred to as a “spoofing” attack. A spoofing attack is an attack that attempts to con one or more users into making security decisions based on a misleading context. This is often in the form of a single web page interface, but can be as involved as an entire web site (or several web sites). This type of attack is especially dangerous because the user is lulled into a false sense of security into a context that is completely controlled by an attacker. The goal for an attacker can range from communicating misleading information to compromising security credentials and other personal information from users. The fundamental trust between the user and the application is leveraged and ultimately violated in spoof attacks. There have been high profile attacks against existing web sites in which user profile data and financial information have been compromised. Transactional communications between client and server are also at risk of being partially or fully circumvented by an attacker attempting to reach an end result without having completed a required process or having provided all required information.
Web spoofing poses a threat to both businesses and end users as authentications or other process flows through web pages become more pervasive. Authentication systems play a critical role in enabling products and services. Web spoofing attacks designed to capture credentials, for example, not only compromise individual user accounts, but also compromise the security of the entire authentication system. In particular, in a single sign-in authentication service, compromise of user credentials results in compromise of credentials at nearly all affiliated sites simultaneously. Users have been educated to expect to see authentication system login pages at increasing locations (e.g., inline sign-in) and to type their password when prompted; therefore, a new unexpected location (e.g., a spoofed location) is not surprising to the user. Any web spoofing attack on an authentication service decreases the trustworthiness of the authentication service. There is a need for tools to help users defend themselves against this kind of attack.
Existing defenses against spoofing attacks primarily focus on user education as the key to combating web spoofs. In other words, spoof detection often requires human intervention. While an informed user base is beneficial, education alone is not sufficient to detect and prevent web spoofing. Contrary to conventional wisdom, reading the address bar in the browser or verifying a secure sockets layer (SSL) certificate is not enough to verify the identity of a website. These tools have been shown to be ineffective at solving the web spoofing problem. For example, an attacker can spoof the web browser itself and show a spoofed address bar, status bar (including SSL lock icon) as well as the SSL dialog. That is, a user reading the address bar and the SSL certificate can still be easily spoofed by an attacker. More specifically, a spoof attacker may take advantage of a legitimate context to help persuade the user of the attack's validity. For example, if an attacker successfully sends an HTML e-mail to a user's e-mail inbox, the content will be rendered in a browser window that legitimately shows the surrounding context of the e-mail service, such as the service's address in the address bar. This context helps the attacker's nefarious mail gain false credibility with the user.
Moreover, investigating the problem by viewing suspicious web pages and taking action based on the investigation is time consuming, expensive, and typically identifies spoofing attempts only after such attempts have successfully fooled one or more users.
Other conventional mechanisms to prevent web spoofing require modifications to the browser software or involve client downloads. However, a majority of users have ignored such systems by failing to download the software modifications. There is a need for a web spoofing solution for users who use a dumb client (e.g., web browser) and will not download additional software. The problem of web spoofing remains given that user education is not enough and that users will not download client software.
FIGS. 1A and 1B demonstrate exemplary spoof attack user experiences according to the prior art in which an attacker leverages a trusted context (i.e., a context with which a user is already familiar). FIG. 1A shows the way a typical e-mail message may be displayed in an electronic inbox. According to this example, a spoof e-mail is sent when an attacker mails an HTML message requesting information from the user such as login name and password.
The exemplary e-mail user interface (UI) of FIG. 1B, shows up in the context of the user's e-mail account and e-mail service provider. Depending on the attacker's level of sophistication, the UI may be made to closely resemble the look of a legitimate maintenance page from the e-mail service provider to the user for display in the user's e-mail program's window. Further to the example, a key idea is that a form such as the one shown in FIG. 1B posts to a change password post acceptor. The user is tricked into entering his or her current password while the UI of FIG. 1B has a hidden field containing a new password set by the attacker rather than the user. A class of vulnerability exists in web services where data is posted directly to a post acceptor, perhaps without the user knowing or with the user being tricked by a disingenuous representation. By doing so, the nefarious e-mail may be posting information to the post acceptor, which in turn does something with the user's information or to the user's account other than what the user intended or is aware of.
For these reasons, a system for authentication of a server by a client to improve prevention of fraudulent user interfaces is desired to address one or more of these and other disadvantages.